Correctly resolve externalRefs that point to the root path - #1963
Correctly resolve externalRefs that point to the root path#1963AmateurECE wants to merge 6 commits into
Conversation
|
Upon further inspection, this only fixes a portion of the failing cases. I've observed two so far--what I'll call "A-B-A," where schemas in B reference schemas in A, and A is the top-level document, but I've discovered a new one--what I'll call "A-B-C-B," where schemas in A reference schemas in B, and schemas in C reference schemas in B. An example schema is given below (not tested yet): foo.yaml bar.yaml: baz.yaml: |
4c79270 to
5049653
Compare
Previously, if OpenAPI v3 document A loads document B, and B refers to schemas in document A, swagger-parser would not resolve references to schemas in A as internal refs, even though they refer to the root OpenAPI v3 document (document A). This would result in the creation of duplicate schemas for those schemas in document A. Now, we resolve these "external" refs as internal refs, preventing the duplication of these schemas by the ExternalRefProcessor.
5049653 to
471a6c9
Compare
|
I believe this fixes all the issues that I have observed. I have not been able to reproduce the "A-B-C-B" case since I originally saw it, so it's entirely possible that was a fluke. I believe this PR is ready for review/merge. |
|
Hi @AmateurECE! We are planning to merge #2383 because it implements that behavior against the current resolver architecture. I have also extended to use URI-based reference identity rather than filesystem Path comparison. That keeps it aligned with the newer normalization work. |
Previously, if OpenAPI v3 document A loads document B, and B refers to schemas in document A, swagger-parser would not resolve references to schemas in A as internal refs, even though they refer to the root OpenAPI v3 document (document A). This would result in the creation of duplicate schemas for those schemas in document A. Now, we resolve these "external" refs as internal refs, preventing the duplication of these schemas by the ExternalRefProcessor.
This fixes issue #1961.